Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

implement hybrid custody #44

Merged
merged 47 commits into from
Jul 31, 2023
Merged

implement hybrid custody #44

merged 47 commits into from
Jul 31, 2023

Conversation

sisyphusSmiling
Copy link
Collaborator

@sisyphusSmiling sisyphusSmiling commented Jul 18, 2023

Closes: #41 #43 #46
Related: #43

Description

Replaces old LinkedAccounts with HybridCustody as hybrid custody solution. Also refactored tests using Cadence testing framework. JS tests have been replaced in favor of Cadence. README will be updated in a fast follow up.

All new contracts are dependencies from the hybrid-custody source repo or standard contracts required locally for VS Code extension support.


For contributor use:

  • Targeted PR against master branch
  • Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
  • Code follows the standards mentioned here.
  • Updated relevant documentation
  • Re-reviewed Files changed in the Github PR explorer
  • Added appropriate labels

@sisyphusSmiling sisyphusSmiling self-assigned this Jul 18, 2023
@sisyphusSmiling sisyphusSmiling changed the title Impl hybrid custody implement hybrid custody Jul 18, 2023
@sisyphusSmiling sisyphusSmiling added enhancement New feature or request SC-Eng labels Jul 18, 2023
@sisyphusSmiling sisyphusSmiling marked this pull request as ready for review July 18, 2023 00:58
Copy link

@satyamakgec satyamakgec left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is hard to every bit and piece. Most of the suggestions for the name change for avoiding confusion and increasing readability. You can ignore if you think otherwise and it is very late to change those names.

return address
}

priv fun parseUInt64(_ input: AnyStruct): UInt64?{

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no code comments in the whole contract, It would be good to have to increase readability.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I should have made it clearer that these are dependencies. The contracts in subdirectories (flow-utils, hybrid-custody, standards, utility) are all dependencies. Goes for a number of comments made below as well.


/// Private interface for Capability retrieval
///
pub resource interface GetterPrivate {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know whether this contract is going to be used as part of the core contract for hybrid custody or not but I don't see the GetterPrivate name doing justice to a resource interface. I can't tell what it is going to do with its name.

Maybe better to rename it to AccessPrivateCapability or RetrievePrivateCapability.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For HC-related naming conventions, could you make an issue if you feel strongly enough about the naming conventions? We've gotten the contracts deployed to Testnet and are shooting for mid-August Mainnet deployment, so we'd want to get any non-upgradable changes discussed and implemented in those contracts in ASAP.


/// Exposes public Capability retrieval
///
pub resource interface GetterPublic {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same for this better to rename to AccessPublicCapability

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above

/// Capabilities is critical to the use case of Hybrid Custody. It's advised to use Factories sparingly and only for
/// cases where Capabilities must be castable by the caller.
///
pub contract CapabilityFactory {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the contract name is confusing, In general factory represents a warehouse where something get created and in the sense of CapabilityFactory it means capabilities are going to be created but it seems the contract functionality is different.

I think the better name is CapabilityFactoryManager or CapabilityFactoryRegistry, Which means a contract which manages the different factories.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The resource that holds Factory implementations is named Manager, so full name CapabilityFactory.Manager which is how it would be named outside of the contract. Do you think that naming convention provides full enough context?

///
/// @param type: The type to add to the allowed types mapping
///
pub fun addType(_ type: Type) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What restrict someone to add the same type in the deny list and that is already existed in the allowlist ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case, addType() is effectively an upsert, where the given Type is added if it doesn't exist and replaced if it does.

/// @param cap: Capability to add
/// @param isPublic: Whether the Capability should be public or private
///
pub fun addCapability(cap: Capability, isPublic: Bool) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know how feasible it is to have the function design like this, It is not consistent with the other functions as other functions are designed specifically for the public/private capabilities while this function differentiates the capability on the basis of the param i.e. isPublic instead of the function name itself like others

pub fun main(addr: Address): AnyStruct {
let manager = getAuthAccount(addr).borrow<&HybridCustody.Manager>(from: HybridCustody.ManagerStoragePath) ?? panic ("manager does not exist")

var typeIdsWithProvider = {} as {Address: [String]}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
var typeIdsWithProvider = {} as {Address: [String]}
var typeIdsWithProvider: {Address: [String]} = {}

Maybe this way it is more cleaner

var typeIdsWithProvider = {} as {Address: [String]}

// Address -> nft UUID -> Display
var nftViews = {} as {Address: {UInt64: MetadataViews.Display}}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here

Copy link
Member

@joshuahannan joshuahannan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm surpised at how few changes were needed!

@sisyphusSmiling sisyphusSmiling merged commit e003ac7 into main Jul 31, 2023
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request SC-Eng
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Implement new Hybrid Custody contracts
3 participants